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i) Dynamic link libraries system and method. 

^ The present invention relates to a system and 
a method for sharing software modules which 
are part of a computer program, and which have 
been previously loaded into a private area (104) 
of main menwry (102) of a computer. The ad- 
dresses of software modules which remain 
loaded in the private area (104) after an execu- 
tion of the computer program are kept track of. 
When a subsequent execution of the computer 
program requires a software module which has 
remained loaded in private area (104), the ad- 
dress of the software module is obtained, and 
the computer program branches to that ad- 
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This invention relates to a system and method for 
the management of memory within a computer. More 
specifically, the present invention relates to a system 
and method for dynamically allocating modules of a 
computer program at run-time, and allowing instances s 
of that computer program to share modules loaded 
Into a private user area. 

Theories and implernentatlons of memory man- 
agement techniques have played a key role in helping 
computers progress to their present state of technol- io 
ogy. Since computers have a finite amount of memory 
capacity, the way in which a computer's memory is 
managed is essential for its efficient operation. This is 
especially true for computers that allow for multi-user 
and/or multi-tasking environments, since memory is 
requirements in such environments can be very large. 

Very frequently, a computer program is designed 
so that it consists of a number of separate software 
modules. These separate software modules are often 
stored together In what Is called a library. When such zo 
a computer program Is executed, only some of those 
software modules may be needed from the library. 
Precisely which modules will be needed may depend 
upon a number of factors, including interactiveiy- 
made user decisions, the type of computer or operat- 25 
ing system being used, etc. 

At present, memory management schemes exist 
where the software modules are dynamically selected 
from the library during the actual execution (or "run- 
time") of the computer program. In this type of 3o 
scheme, the library is often refen«d to as a "run-time" 
or 'dynamic link" library. In a prefenred embodiment, 
the modules of the library comprise reentrant code. 

During the operation of such a scheme using a 
dynamic link library, a front-end or "initialization mod- 35 
ule" is typically loaded Into the main memory of the 
computer which Is executing the computer program. 
As the program executes, additional software mod- 
ules may be required. Any additional modules are 
loaded Into main memory when needed from the 40 
dynamic link library. In this way, only those modules 
which are required are loaded Into main memory. 
Otherwise, the entire computer program would have 
to be loaded into main memory at the beginning of 
executton. Thus, the use of schemes using dynamic 45 
link libraries allow the main memory of computers to 
be more efficiently utilized. 

On typical multi-user machines, any number of 
computer programs can be made available to a given 
user. hHowever, It Is often the case that more than one so 
user will want to execute the same computer program 
at the same time or, for that matter, the same user may 
request that the same computer program be executed 
multiple times concurrently. In multi process/multi- 
user environments, when such requests to execute a 55 
computer program are made, each request is said to 
generate another process or "instance' of that com- 
puter program. An instance generally represents the 



existence of another logical copy of the computer pro- 
gram which is ready to execute. In a sense, it repre- 
sents a "desire" to execute a particular computer 
program, along with some specific parameters and 
data. 

in conventional computer architecture, each inst- 
ance is put on some kind of queue and has to wait its 
turn to make use of the facilities of the computer. 
(Such facilities include the computer's memory, cent- 
ral processing unit, ete.). When an Instance takes its 
turn to access the facilities, the Instance will have 
more-or-less full control, but only for a limited duration 
of time. This concept is generally known as "time- 
sharing," and is a scheme used in most multi-user 
environments. Whether the instance Is stored some- 
where in main memory or on some storage device 
such as a disk drive Is usually a decision made by the 
operating system of the computer. 

Figure 1 shows a conventional memory manage- 
ment scheme which takes advantage of some of the 
concepts noted above. Referring to Figure 1, main 
memory 102 is divided into a private area 104 and a 
common area 106. The private area 104 represents 
an address area of main memory 102 which is allo- 
cated to the specific computer programs and data 
used by the users. Thus, when a user executes a com- 
puter program, It Is generally loaded into these private 
address areas. 

While the private area 1 04 may be available to the 
current instance (that Is, the instance presently in con- 
trol), the actual computer programs or modules that 
may be stored there from prevkius instances are not. 
With conventtonal technology, to do otherwise could 
potentially cause a break-down in integrity and/or sec- 
urity. Also, in keeping with the general philosophy that 
a given instance is granted what it at least perceives 
as full use of the facil ities of the computer, to do other- 
wise would run counter to this philosophy. 

Since the private area 104 does not penmit Inst- 
ances to gain access to the previous work of other 
instances, the memory management scheme shown 
in Figure 1 also contemplates the existence of a com- 
mon area 106 of main memory 102. This common 
area 106 is generally accessible to the cunent Inst- 
ance, and computer programs which are frequently 
used are loaded Into this area. In this way, if many 
instences simultaneously request a partk:ular com- 
puter program, they can all access and share the com- 
puter program in the common area 106 without each 
instance having to load the computer program into pri- 
vate area 104. The basis of this scheme Is that a 
user's own personal computer programs and data 
cannot be written to the common area. This means 
that anything stored In common area 106 Is not 
directly affected each time another instence tekea 
control of the computer (that Is, not directly affected by 
the impact of time-sharing). 

In addition, the common area scheme shown in 
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Figure 1 also contemplates that a computer program 
can be loaded Into the common area 106 as a 
dynamic link library. In this way, each time a user 
executes such a computer program, only those mod- 
ules needed will be loaded into the common area 106. s 
Once loaded, the computer program then branches to 
the appropriate address in the common area 1 06 to 
access the loaded software module. 

The scheme of Figure 1 further contemplates that 
the computer can keep track of exactly which software io 
modules have been loaded into the computer by pre- 
vk>u6 Instances, and what the addresses of those 
software modules are. Thus, where the current inst- 
ance requests a module that is already loaded, it can 
branch to the address of the appropriate software is 
module In the common area 1 06 without having to re- 
load the software module. The ability to continuously 
store the addresses of these software modules is enh- 
anced by the fact that the addresses themselves can 
be kept in the common area 1 06, which is not directly 20 
affected by the Impact of time-sharing. 

Although perhaps an Improvement from previous 
techniques, the memory management scheme des- 
cribed above with regard to Figure 1 still suffers from 
some disadvantages. For example, the common area 25 
106 in such a scheme is usually a scarce resource in 
which only a limited amount of storage is available. In 
addition, in many large multi-user environments, the 
systems programmer must consent to allowing any 
computer program to be made accessible from the 30 
common area 106. This adds an extra step in the pro- 
cess, and one which the systems programmer may 
not want to take, especially If he or she feels that not 
enough people are going to utilize the computer pro- 
gram to make it worthwhie. 35 

What Is thus needed Is a scheme to allow sharing 
of previously loaded software modules without having 
to place them in common areas. 

The present invention overcomes the deficien- 
cies of the previous techniques by providing a system 40 
and method for sharing previously loaded software 
modules which are part of a computer program with- 
out having to place them in a common area of main 
memory of a computer system. More specifically, the 
present invention keeps track of the location of any 45 
software modules whtoh remain, loaded in a private 
area of main memory, having been loaded by a pre- 
vious execution of the computer program. In this way, 
a subsequent execution of that computer program 
requiring those software modules can immediately so 
access them rather than having to re-load them Into 
memory. 

The addresses for the software modules which 
have been loaded into main memory are kept in a 
memory location which is not directly affected by the 55 
impact of time-sharing. The software modules them- 
selves are loaded into the private area of mennory, 
and are in effect stored in that area for possible later 



use by a subsequent execution of the same computer 
program. 

Accordingly the present invention relates to a sys- 
tem for memory management of a computer having a 
main memory, comprising: 

- first means for generating a first instance of a 
computer program; 

- second means for loading a software module 
into a private area of the majn memory as 
required by said first instance of said computer 
program, and for generating an address of said 
software nrwdule; 

- a global environment area for storing said 
address of said software module; 

- third means for generating a second instance of 
said computer program; 

- fourth means for detemiining whether said sec- 
ond instance requires said software module; and 

- fifth means for obtaining said address of said 
software module from said global environment 
area, and for branching to said address. 
According to another aspect the present inven- 
tion also relates to a method for memory manage- 
ment, comprising: 

(1) spawning a first instance of a computer prog- 
ram, having at least one software module, and 
loading a software module of said computer pro- 
gram into a private area of a main memory of a 
computer; 

(2) generating an address of said software mod- 
ule, and storing said address in a global environ- 
ment area; 

(3) spawning a second instance of said computer 
program; 

(4) establishing whether said second instance 
requires saki software module which has been 
previously loaded Into said private area by said 
first instance of said computer program; 

(5) upon establishing that said second instance 
requires said software module, obtaining said 
address from said global environment area; and 

(6) branching to said address. 

Various objects, features, and attendant advan- 
tages of the present invention can be more fully 
appreciated as the same become better understood 
with reference to the following detailed description of 
the present invention when considered in connection 
with the accompanying drawings, In which: 

Figure 1 shows a conventional memory manage- 
ment scheme. 

Figure 2 Is a high-level diagram of the present 
invention. 

Figure 3 is a low-level diagram of the present 
invention. 

Figure 4 is a flow diagram of the operatton of the 
present invention. 

The present invention relates to a system and 
method for the management of memory within a com- 
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puter. More specifically, the present invention relates 
to a system and method for dynamically allocating 
modules of a computer program at run-time, and 
allowing Instances of that computer program to 
access software modules previously loaded into a pri- 
vate user area. 

An overview of the present invention can best be 
described with reference to Figure 2. This figure Illus- 
trates the basic sequence of events which are part of 
the present invention. As shown by Figure 2, a first 
Instance of a computer program is executed (as indi- 
cated by User Instance 1), and an initialization module 
Is loaded into the private area 104 of main memory 
102. As this instance is executed, additional software 
modules for this instance are dynamically allocated as 
needed. By way of example, the n+1 software mod- 
ules shown in Figure 2 represent those software modr 
ules which were needed by User Instance 1 which 
were consequently loaded Into private area 104. 

Assume now that a second user requests execu- 
tion of the same computer program. This will create 
another Instance (designated as User Instance 2) 
which, when it becomes the current instance, will load 
another initialization module Into private area 104. If 
during the execution of user instance 2 module n of 
the computer program is needed, then if this module 
Is not yet loaded, it will be loaded Into private area 
104. This newly loaded software module will then be 
branched to, and the computer progiam will continue 
executing. 

However, if module n has already been loaded by 
a previous Instance, then User Instance 2 will obtain 
the address of this module, and will branch to it rather 
than re-load it. In the example shown by Figure 2, 
module n has already been loaded by user instance 
1 , so that module n can be branched to without having 
to be re-loaded. 

In implementing the present invention, when User 
Instance 2 becomes the current instance, it must be 
effected that the software modules which were previ- 
ously loaded and may be needed by the current inst- 
ance are not over-written. It is contemplated that this 
Is taken care of by the operating system when It stores 
an instance between the times when the instance has 
control of the computer. In addition, It Is also contem- 
plated that the addresses of these modules are kept 
In some location of memory so that they too will not 
be over-written. 

In general, it can be seen that the present inven- 
tion allows for softvtrare modules to be loaded into the 
private area 104 of memory 102 by one instance whe- 
rein these software modules are subsequently 
accessible to other instances without having to load 
the software modules Into the vahjable space of com- 
mon area 106. In effect, each software module need 
only be loaded into the private area 104 once. 
Moreover, this scheme does not need to make use of 
common area 106, nor does it result in corrupting the 



integrity or compromising the security of the software 
modules within the private area 104. 

Although the above descriptton (as well as that 
which fdtows] implies that there are two users invol- 

5 ved, it should be understood that the present inven- 
tion also contemplates more than two users, as well 
as a single user executing two Instances of a com- 
puter program in parallel. Thus, the description of two 
users Is merely for purposes of example. 

10 Figure 3 shows a prefered embodiment of the 

present Invention contemplating the use of the MVS 
operating system (available from International Busi- 
ness Machines, Armonl< NY) employing cross mem- 
ory and extended memory. (For more Information on 

15 this operating system, see chapters 1 -3 of I BM pu bl I- 
cation GC21-1854, entitled "MVS/ESA SPL: Appli- 
catkin Development - Extended Addressability.") 
Because this environment is a multi-user/multi- 
processing environment as described above. User 1 

20 Memory Area as shown in Figure 3 Indicates how 
User Instance 1 views main memory 102 while it is in 
control of the computer (that is, while It is the current 
Instance). Simllariy, User 2 Memory Area shows how 
User Instance 2 views main memory 102 while it has 

25 control. It should be understood that while the MVS 
operating system is mentioned as part of a prefenred 
embodiment, that the present invention can also be 
used in a multitude of other multi-user/multlproces- 
slng environments employing cross memory or the 

30 like. 

As shown in Figure 3, main memory 102 Is further 
sub-divided to include an extended private area 302 
and extended common area 304. These areas func- 
tion in the same way as private area 104 and common 

35 area 106, and merely serve as extended address 
areas for computer programs and data which are able 
to take advantage of this extended amount of mem- 
ory. It should be understood that these extended 
areas are not critical to the functioning and purpose 

40 of the present Invention. 

The structure and operation of a preferred embo- 
diment of the present inverition will now be explained 
with regard to Figure 3. When a first user executes a 
computer program. User Instance 1 is generated (and 

4S is the current Instance), and an initialization module is 
loaded into memory. Figure 3 shows this to have 
occun'ed in extended private area 302, but this is just 
by way of example, and could also have occurred In 
private area 104. In any event, the present Invention 

so contemplates that a pool of address spaces be kept 
available for the creation of new instances, and for the 
additional memory needs of existing ones. 

When User Instance 1 has been generated and 
is in control of the computer. User 1 Memory Area as 

55 shown in Figure 3 is how this instance perceives main 
memory 102. As the computer program of User Inst- 
ance 1 executes, other software modules that are 
needed to continue execution are loaded into main 
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memory 102. As indicated in the example of Figure 3 
module n Is representative of one such software mod- 



As User instance 1 loads software modules into 
main memory 102. the addresses of the software 
modules for each instance of a computer program are 
generated and stored within a global environment 
area 306. In a preferred embodiment shown in Figure 
3. this global environment area 306 is part of main 
memory 102, although it should be understood that 
this does not have to be the case. As the name 
implies, any infonnation which is stored in the global 
environment area 306 does not change as control of 
the computer is handed over from one instance to the 
next. In this way. when the address of a software mod- 
ule is put into the global environment area 306 a sub- 
sequent instance which takes control from the prior 
instance will be able to access that address that was 
put Into the global environment area 306. 

When the time allotted to User Instance 1 has 
expired, the next instance in line on the queue takes 
control, as indicated here by User Instance 2. As indi- 
cated above, the operating system will store the pre- 
vious current instance (in this case, User Instance 1) 
either on a storage device such as a disk drive, or else 
l<eep it in main memory 102. If that portion of main 
memory is subsequently needed by the computer for 
the current instance, then the stored instance will be 
moved to an alternate storage device until it is again 
its turn to control the computer. In any event, any 
movement of the instance or portions thereof will 
update the global environment area 306. 

In the example shown by Figure 3, User Instance 
2 IS an instance of the same computer program as 
User Instance 1. Also in this example, it is shown that 
the initialization module for User Instance 2 was 
loaded Into private area 104. It should be understood 
however, that User Instance 2 could just as easily 
have been generated in some other private area of 
memory such as extended private area 302. 

During the duration of time that User Instance 2 
has control of the computer, User 2 Memory Area is 
how It views the memoryavailabletoit Software mod- 
ules may still be resident in main memory 102, but 
these are transparent to User Instance 2. 

When User Instance 2 is the current instance and 
requires another module for its execution, it first 
checks to see if it has already loaded the required 
software module itself. If it has not, it checks the global 
environment area 306 to assess whether another inst- 
ance of the computer program has previously loaded 
the required module into memory. If this is the case 
It gets the address of the software module from the 
global environmentarea 306, branches to the address 
of the needed module, and begins to execute the 
required module. As shown by Figure 3. User Inst- 
ance 2 was in need of module n. It consequently bran- 
ched to the address where User Instance 1 had 



loaded it, as shown by arrow 3 10. 

Since the computer program being executed may 
have been written using a compiler requiring that cer- 
tain compiler run-time modules be constantly loaded 
5 somewhere in main memory 102, Figure 3 further 
shows that a compiler mn-time library has been 
placed in the extended common area 304. However 
it should be noted that depending upon the compiler 
or the way that the computer program has been 
10 created, such a compiler run-time library may not be 
necessary. This is pointed out in Figure 3 merely to 
show that the use of common areas to load computer 
programs can also be used in conjunctton with the 
present invention. 
« The operation of the present invention will nowbe 

described with reference to the flow chart of Figure 4. 

Refening now to Figure 4, the first step in the 
operation of the present invention entails spawning a 
first instance of a computer program, as indicated by 
20 block 402. The next step entails the loading of a 
software module of that computer program into the 
pnvate area 104 of main memory 102 by the first inst- 
ance, as indicated by block 404. Once loaded into the 
pnvate area, the next step involves generating and 
25 stonng an address (or addresses) of this software 
module into the global environment area 306 as indi- 
cated by block 406. 

When the first instance has completed its turn of 
using the computer's facilities and the same computer 
30 program is executed, a second instance of the com- 
puter program is spawned, as shown by block 408 
During its execution, the second instance may 
request the same software module that was loaded 
into the private area by the first instance, as indicated 
3« by block410. If this oocure. the present Invention pur- 
sues the step of establishing whether the requested 
software module has previously been loaded into the 
pnvate area of memory, as indicated by decision 
bk)ck412. 

40 If the requested software module has not previ- 
ously been loaded into the private area 1 04. then the 
next step involves loading the requested software 
module into the private area 104, as indicated by 
block 414. However, if the requested software module 
46 has been previously loaded, then the next step will be 
obtaining the address of the software module from the 
global environment area 306, as indicated by block 
416. Subsequently, the next step involves branching 
to the address obtained from the global environment 
50 area 306, as indk:ated by block 418. 

It should be understood that present invention is 
not limited to Its preferred embodiments, and that the 
examples presented above are merely for the pur- 
poses of illustration. The scope of the present inv6n- 
55 tion should therefore be interpreted by the following 
claims as defined by the forgoing figures and text 
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Claims 

1. System for memory management of a computer 
having 9 main memory (1 02), comprising: 

- first means for generating a first instance 
(User instance 1) of a computer program; 

- second means for ioading a software mod- 
; ule into a private area (104) of the main mem- 
ory (1 02) as required by said first instance of 
said computer program, and for generating an 
address of said software module; 

- a global environment area (306) for storing 
said address of said software module; 

- third means for generating a second inst- 
ance (User instance 2) of said computer pro- 
gram; 

- fourth means for detemiining whether said 
second instance (User Instance 2) requires 
said software module; and 

- fifth means for obtaining said address of 
said software module from said global envi- 
ronment area (306). and for branching to said 



6. H4ethod according to claim 5, wherein said muiti- 
user/multi-processlng environment is using an 
MVS environment. 



2. System according to claim 1 , wherein said com- 
puter program of said first means operates in a 
multi-user/multi-processing environment. 

3. System according to claim 2, wherein said multi- 
user/multi-processing environment is MVS. 

4. Method for memory management, comprising: 

(1) spawning (402) a first instance of a com- 
puter program, having at least one software 
module, and ioading (404) a software module 
of said computer program into 9 private area 
(104) of a main memory (102) of a eomputen 

(2) generating (406) an address of said 
software module, and storing (406) said 
address in a global environment area (306); 

(3) spawning (408) a second instance of said 
computer program; 

(4) establishing (410, 412) whether said sec- 
ond instance requires said software module 
which has been previously loaded into said 
private area by said first instance of said com- 
puter program; 

(5) upon establishing that said second Inst- 
ance requires said software module, obtaining 
(416) said address from said global environ- 
ment area (306); and 

(6) branching (418) to said address. 

,5. Method according to claim 4, wherein said com- 
puter program of step (1) comprises the step of 
operating in a muiti-user/multi-processing envi- 
ronment. 
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@ Dynamic iinit libraries system and method. 

@ The present invention relates to a system and 
a method for sharing software modules which 
are part of a computer program, and which have 
been previously loaded into a private area (104) 
of main memory (102) of a computer. The ad- 
dresses of software modules which remain 
loaded in the private area (104) after an execu- 
tion of the computer program are l<ept tracts of. 
When a subsequent execution of the computer 
program requires a software module which has 
remained loaded in private area (104), the ad- 
dress of the software module is obtained, and 
the computer program branches to that ad- 
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